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Abstract

   This document describes the framework for an RFC Series and an RFC
   Editor function that incorporate the principles of organized
   community involvement and accountability that has become necessary as
   the Internet technical community has grown, thereby enabling the RFC
   Series to continue to fulfill its mandate.
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1.  Introduction

   The first Request for Comments (RFC) document was published in April
   of 1969 as part of the effort to design and build what we now know of
   as the Internet.  Since then, the RFC Series has been the archival
   series dedicated to documenting Internet technical specifications,
   including both general contributions from the Internet research and
   engineering community as well as standards documents.

   As described in the history of the first 30 years of RFCs
   ([RFC2555]), the RFC Series was created for the purpose of capturing
   the research and engineering thought that underlie the design of
   (what we now know of as) the Internet.  As the Internet Engineering
   Task Force (IETF) was formalized to carry out the discussion and
   documentation of Internet standards, IETF documents have become a
   large part (but not the entirety) of the RFC Series.

   As the IETF has grown up and celebrated its own 20 years of history,
   its requirements for archival publication of its output have changed
   and become more rigorous.  Perhaps most significantly, the IETF must
   be able to define (based on its own open consensus discussion
   processes and leadership directions) and implement adjustments to its
   publication processes.

   At the same time, the Internet engineering and research community as
   a whole has grown and come to require more openness and
   accountability in all organizations supporting it.  More than ever,
   this community needs an RFC Series that is supported (operationally
   and in terms of its principles) such that there is a balance of:

   o  expert implementation;

   o  clear management and direction -- for operations and evolution
      across the whole RFC Series (whether originating in the IETF or
      not); and

   o  appropriate community input into and review of activities.

   Today, there is confusion and therefore sometimes tension over where
   and how to address RFC issues that are particular to contributing
   groups (e.g., the IETF, the Internet Architecture Board (IAB), or
   independent individuals).  It isn't clear where there should be
   community involvement versus RFC Editor control; depending on the
   issue, there might be more or less involvement from the IAB, the
   Internet Engineering Steering Group (IESG), or the community at
   large.  There are similar issues with handling RFC Series-wide issues
   -- where to discuss and resolve them in a way that is balanced across
   the whole series.
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   For example, there are current discussions about Intellectual
   Property Rights (IPR) for IETF-generated documents, but it's not
   clear when or how to abstract the portions of those discussions that
   are relevant to the rest of the RFC Series.  Discussions of labeling
   (of RFCs in general, IETF documents in particular, or some
   combination thereof) generally must be applied on an RFC Series-wide
   basis or not at all.  Without an agreed-on framework for managing the
   RFC Series, it is difficult to have those discussions in a non-
   polarized fashion -- either the IETF dictating the reality of the
   rest of the RFC Series, or the RFC Series imposing undue restrictions
   on the IETF document series.

   As part of its charter (see Appendix A), the IAB has a responsibility
   for the RFC Editor.  Acknowledging the IETF's and the general
   Internet engineering and research community's evolving needs, the IAB
   would like to see a future for the RFC Series that continues to meet
   its original mandate of providing the archival series for the
   technical research and engineering documentation that describes the
   Internet.

   With this document, the IAB provides the framework for the RFC Series
   and an RFC Editor function with the specific purpose of ensuring that
   the RFC Series is maintained and supported in ways that are
   consistent with the stated purpose of the RFC Series and the
   realities of today's Internet research and engineering community.
   The framework describes the existing "streams" of RFCs, draws a
   roadmap of existing process documents already defining the
   implementation, and provides clear direction of how to evolve this
   framework and its supporting pieces through discussion and future
   document revision.

   Specifically, this document provides a brief charter for the RFC
   Series, describes the role of the RFC Editor, the IAB, and the IETF
   Administrative Support Activity (IASA) in a framework for managing
   the RFC Series, and discusses the streams of input to the RFC Series
   from the various constituencies it serves.

2.  RFC Series Mission

   The RFC Series is the archival series dedicated to documenting
   Internet technical specifications, including general contributions
   from the Internet research and engineering community as well as
   standards documents.

   RFCs are available free of charge to anyone via the Internet.
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3.  Roles and Responsibilities

   As this document sets out a revised framework for supporting the RFC
   Series mission, this section reviews the updated roles and
   responsibilities of the entities that have had, and will have,
   involvement in continued support of the mission.

3.1.  RFC Editor

   Originally, there was a single person acting as editor of the RFC
   Series (the RFC Editor).  The task has grown, and the work now
   requires the organized activity of several experts, so there are RFC
   Editors, or an RFC Editor organization.  In time, there may be
   multiple organizations working together to undertake the work
   required by the RFC Series.  For simplicity's sake, and without
   attempting to predict how the role might be subdivided among them,
   this document refers to this collection of experts and organizations
   as the "RFC Editor".

   The RFC Editor is an expert technical editor and series editor,
   acting to support the mission of the RFC Series.  As such, the RFC
   Editor is the implementer handling the editorial management of the
   RFC Series, in accordance with the defined processes.  In addition,
   the RFC Editor is expected to be the expert and prime mover in
   discussions about policies for editing, publishing, and archiving
   RFCs.

3.2.  IAB

   In this model, the role of the IAB is to ensure that the RFC Series
   mission is being appropriately fulfilled for the whole community for
   which it was created.  The IAB does not, organizationally, have
   comprehensive publishing or editorial expertise.  Therefore, the role
   of the IAB as put forward in this document is focused on ensuring
   that principles are met, the appropriate bodies and communities are
   duly informed and consulted, and the RFC Editor has what it needs in
   order to execute on the material that is in their mandate.

   It is the responsibility of the IAB to approve the appointment of the
   RFC Editor and to approve the general policy followed by the RFC
   Editor.

3.3.  Operational Oversight

   The IETF Administrative Support Activity (BCP 101, [BCP101]) was
   created to provide administrative support for the IETF, the IAB, and
   the Internet Research Task Force (IRTF).  In its role of supporting
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   the IAB, the IASA is tasked with providing the funding for and
   operational oversight of the RFC Editor.

   The IAOC (IETF Administrative Oversight Committee) is the oversight
   board of the IASA, and the IAD (IETF Administrative Director) is the
   chief actor for the IASA.

   The IAOC works with the IAB to identify suitable persons or entities
   to fulfill the mandate of the RFC Editor.

   The IAOC establishes appropriate contractual agreements with the
   selected persons or entities to carry out the work that will satisfy
   the technical publication requirements defined for the various RFC
   input streams (see Section 5.2).  The IAOC may define additional
   operational requirements and policies for management purposes to meet
   the requirements defined by the various communities.

   In accordance with BCP 101, the IAOC provides oversight of the
   operation of the RFC Editor activity based on the established
   agreements.

3.4.  Policy Oversight

   The IAB monitors the effectiveness of the policies in force and their
   implementation to ensure that the RFC Editor activity meets the
   editorial management and document publication needs as referenced in
   this document.  In the event of serious non-conformance, the IAB,
   either on its own initiative or at the request of the IAOC, may
   require the IAOC to vary or terminate and renegotiate the
   arrangements for the RFC Editor activity.

4.  Framework

   With the RFC Series mission outlined above, this document describes a
   framework for supporting

   o  the operational implementation of the RFC Series,

   based on

   o  public process and definition documents,

   for which there are

   o  clear responsibilities and mechanisms for update and change.
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   Generally speaking, the RFC Editor is responsible for the operational
   implementation of the RFC Series.  As outlined in Section 3.3, the
   IAD provides the oversight of this operational role.

   The process and definition documents are detailed below, including
   responsibility for the individual process documents (maintenance and
   update).  The RFC Editor works with the appropriate community to
   ensure that the process documents reflect current requirements.  The
   IAB is charged with the role of verifying that appropriate community
   input has been sought and that any changes appropriately account for
   community requirements.

   There are 3 categories of activity, and a 4th category of series-wide
   rules and guidelines, described for implementing the RFC Series to
   support its mission:

   o  Approval of documents.

   o  Editing, processing, and publication of documents.

   o  Archiving and indexing the documents and making them accessible.

   o  Series rules and guidelines.

4.1.  Document Approval

   The RFC Series mission implicitly requires that documents be reviewed
   and approved for acceptance into the series.

4.1.1.  Definition

   Section 5.1 describes the different streams of documents that are put
   to the RFC Editor for publication as RFCs today.  While there may be
   general policies for approval of documents as RFCs (to ensure the
   coherence of the RFC Series), there are also policies defined for the
   approval of documents in each stream.  Generally speaking, there is a
   different approving body for each stream.  The current definitions
   are catalogued in Section 5.1.

4.1.2.  Operational Implementation

   Each stream has its own documented approval process.  The RFC Editor
   is responsible for the approval of documents in one of the streams
   (Independent Submission stream, see Section 5.1.4) and works with the
   other approving bodies to ensure smooth passage of approved documents
   into the next phases, ultimately to publication and archiving as an
   RFC.
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4.1.3.  Process Change

   From time to time, it may be necessary to change the approval
   processes for any given stream, or even add or remove streams.  This
   may occur when the RFC Editor, the IAB, the body responsible for a
   given stream of documents, or the community determines that there are
   issues to be resolved in general for RFC approval or for per-stream
   approval processes.

   In this framework, the general approach is that the IAB will work
   with the RFC Editor and other parties to get community input and it
   will verify that any changes appropriately account for community
   requirements.

4.1.4.  Existing Approval Process Documents

   The existing documents describing the approval processes for each
   stream are detailed in Section 5.1.

4.2.  Editing, Processing, and Publication of Documents

   Producing and maintaining a coherent, well-edited document series
   requires specialized skills and subject matter expertise.  This is
   the domain of the RFC Editor.  Nevertheless, the community served by
   the RFC Series and the communities served by the individual streams
   of RFCs have requirements that help define the nature of the series.

4.2.1.  Definition

   General and stream-specific requirements for the RFC Series are
   documented in community-approved documents (catalogued in Section 5.2
   below).

   Any specific interfaces, numbers, or concrete values required to make
   the requirements operational are the subject of agreements between
   the IASA and the RFC Editor (e.g., contracts, statements of work,
   service level agreements, etc).

4.2.2.  Operational Implementation

   The RFC Editor is responsible for ensuring that editing, processing,
   and publication of RFCs are carried out in a way that is consistent
   with the requirements laid out in the appropriate documents.  The RFC
   Editor works with the IASA to provide regular reporting and feedback
   on these operations.
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4.2.3.  Process Change

   From time to time, it may be necessary to change the requirements for
   any given stream, or the RFC Series in general.  This may occur when
   the RFC Editor, the IAB, the approval body for a given stream of
   documents, or the community determines that there are issues to be
   resolved in general for RFCs or for per-stream requirements.

   In this model, the general approach is that the IAB will work with
   the RFC Editor to get community input and it will approve changes by
   validating appropriate consideration of community requirements.

4.2.4.  Existing Process Documents

   Documents describing existing requirements for the streams are
   detailed in Section 5.2.

4.3.  Archiving, Indexing, and Accessibility

   The activities of archiving, indexing, and making accessible the RFC
   Series can be informed by specific subject matter expertise in
   general document series editing.  It is also important that they are
   informed by requirements from the whole community.  As long as the
   RFC Series is to remain coherent, there should be uniform archiving
   and indexing of RFCs across all streams and a common method of
   accessing the resulting documents.

4.3.1.  Definition

   In principle, there should be a community consensus document
   describing the archiving, indexing, and accessibility requirements
   for the RFC Series.  In practice, we continue with the archive as
   built by the capable RFC Editors since the series' inception.

   Any specific concrete requirements for the archive, index, and
   accessibility operations are the subject of agreements between the
   IASA and the RFC Editor (e.g., contracts, statements of work, service
   level agreements, etc).

4.3.2.  Operational Implementation

   The RFC Editor is responsible for ensuring that the RFC archive and
   index are maintained appropriately and that the resulting documents
   are made available to anybody wishing to access them via the
   Internet.  The RFC Editor works with the IASA for regular reporting
   and feedback.
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4.3.3.  Process Change

   Should there be a community move to propose changes to the
   requirements for the RFC archive and index or accessibility, the IAB
   will work with the RFC Editor to get community input and it will
   approve changes by validating appropriate consideration of community
   requirements.

4.3.4.  Existing Process Documents

   There are no applicable process documents.

4.4.  Series-Wide Guidelines and Rules

   The RFC Series style and content can be shaped by subject matter
   expertise in document series editing.  They are also informed by
   requirements by the using community.  As long as the RFC Series is to
   remain coherent, there should be uniform style and content for RFCs
   across all streams.  This includes, but is not limited to, acceptable
   language, use of references, and copyright rules.

4.4.1.  Definition

   In principle, there should be a community consensus document (or set
   of documents) describing the content requirements for the RFC Series.
   In practice, some do exist, though some need reviewing and more may
   be needed over time.

4.4.2.  Operational Implementation

   The RFC Editor is responsible for ensuring that the RFC Series
   guidelines are upheld within the RFC Series.

4.4.3.  Process Change

   When additions or changes are needed to series-wide definitions, the
   IAB will work with the RFC Editor and stream stakeholders to get
   community input and review.  The IAB will approve changes by
   validating appropriate consideration of community requirements.

4.4.4.  Existing Process Documents

   Existing series-wide rules and guidelines documents include:

   o  Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS])

   o  Copyright and intellectual property rules (RFC 3978 [RFC3978] and
      RFC 4748 [RFC4748])
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   o  Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897])

5.  RFC Streams

   Various contributors provide input to the RFC Series.  These
   contributors come from several different communities, each with its
   own defined process for approving documents that will be published by
   the RFC Editor.  This is nothing new; however, over time the various
   communities and document requirements have grown and separated.  In
   order to promote harmony in discussing the collective set of
   requirements, it is useful to recognize each in their own space --
   and they are referred to here as "streams".

   Note that by identifying separate streams, there is no intention of
   dividing them or undermining their management as one series.  Rather,
   the opposite is true -- by clarifying the constituent parts, it is
   easier to make them work together without the friction that sometimes
   arises when discussing various requirements.

   The subsections below identify the streams that exist today.  There
   is no immediate expectation of new streams being created and it is
   preferable that new streams NOT be created.  Creation of streams and
   all policies surrounding general changes to the RFC Series are
   discussed above in Section 4.

5.1.  RFC Approval Processes

   Processes for approval of documents (or requirements) for each stream
   are defined by the community that defines the stream.  The IAB is
   charged with the role of verifying that appropriate community input
   has been sought and that the changes are consistent with the RFC
   Series mission and this overall framework.

   The RFC Editor is expected to publish all documents passed to it
   after appropriate review and approval in one of the identified
   streams.

5.1.1.  IETF Document Stream

   The IETF document stream includes IETF WG documents as well as
   "individual submissions" sponsored by an IESG area director.  Any
   document being published as part of the IETF standards process must
   follow this stream -- no other stream can approve Standards-Track or
   Best Current Practice (BCP) RFCs.
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   Approval of documents in the IETF stream is defined by

   o  the IETF standards process (RFC 2026 [RFC2026] and its
      successors).

   o  the IESG process for sponsoring individual submissions [SPONSOR]).

   Changes to the approval process for this stream are made by updating
   the IETF standards process documents.

5.1.2.  IAB Document Stream

   The IAB defines the processes by which it approves documents in its
   stream.  Consistent with the above, any documents that the IAB wishes
   to publish as part of the IETF Standards Track (Standards or BCPs)
   are subject to the approval processes referred to in Section 5.1.1.

   The review and approval process for documents in the IAB stream is
   described in

   o  the IAB process for review and approval of its documents (RFC 4845
      [RFC4845]).

5.1.3.  IRTF Document Stream

   The IRTF is chartered as an activity of the IAB.  With the approval
   of the IAB, the IRTF may publish and update a process for publication
   of its own, non-IETF Standards-Track, documents.

   The review and approval process for documents in the IRTF stream is
   described in

   o  IRTF Research Group RFCs [IRTF-DOCS].

5.1.4.  Independent Submission Stream

   The RFC Series has always served a broader Internet technical
   community than the IETF.  The "Independent Submission" stream is
   defined to provide review and (possible) approval of documents that
   are outside the scope of the streams identified above.

   Generally speaking, approval of documents in this stream falls under
   the purview of the RFC Editor, and the RFC Editor seeks input to its
   review from the IESG.
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   The process for reviewing and approving documents in the Independent
   Submission stream is defined by

   o  Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).

   o  The IESG and RFC Editor Documents: Procedures (RFC 3932
      [RFC3932]).

5.2.  RFC Technical Publication Requirements

   The Internet engineering and research community has not only grown,
   it has become more diverse, and sometimes more demanding.  The IETF,
   as a standards-developing organization, has publication requirements
   that extend beyond those of an academic journal.  The IAB does not
   have the same interdependence with IANA assignments as the IETF
   stream does.  Therefore, there is the need to both codify the
   publishing requirements of each stream, and endeavor to harmonize
   them to the extent that is reasonable.

   Therefore, it is expected that the community of effort behind each
   document stream will outline their technical publication
   requirements.

   As part of the RFC Editor oversight, the IAB must agree that the
   requirements are consistent with and implementable as part of the RFC
   Editor activity.

5.2.1.  IETF Documents

   The requirements for this stream are defined in RFC 4714 [RFC4714].

5.2.2.  IAB Documents

   Although they were developed for the IETF standards process, the IAB
   will identify the applicable requirements in RFC 4714 for its stream.

   If the IAB elects to define other requirements, they should deviate
   minimally from those (in an effort to keep the collective technical
   publication requirements reasonably managed by one technical
   publisher).

5.2.3.  IRTF Documents

   Although they were developed for the IETF standards process, the IRTF
   will identify the applicable requirements in RFC 4714 for its stream.

   If the IRTF elects to define other requirements, they should deviate
   minimally from those (in an effort to keep the collective technical
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   publication requirements reasonably managed by one technical
   publisher).

5.2.4.  Independent Submissions

   Although they were developed for the IETF standards process, the RFC
   Editor will identify the applicable requirements in RFC 4714 for its
   stream.

   If the RFC Editor elects to define other requirements, they should
   deviate minimally from those (in an effort to keep the collective
   technical publication requirements reasonably managed by one
   technical publisher).

6.  Security Considerations

   The processes for the publication of documents must prevent the
   introduction of unapproved changes.  Since the RFC Editor maintains
   the index of publications, sufficient security must be in place to
   prevent these published documents from being changed by external
   parties.  The archive of RFC documents, any source documents needed
   to recreate the RFC documents, and any associated original documents
   (such as lists of errata, tools, and, for some early items, non-
   machine readable originals) need to be secured against failure of the
   storage medium and other similar disasters.

7.  IAB Members at the Time of Approval

   Bernard Aboba
   Loa Andersson
   Brian Carpenter
   Leslie Daigle
   Elwyn Davies
   Kevin Fall
   Olaf Kolkman
   Kurtis Lindqvist
   David Meyer
   David Oran
   Eric Rescorla
   Dave Thaler
   Lixia Zhang
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Appendix A.  A Retrospective of IAB Charters and RFC Editor

   With this document, the IAB's role with respect to the RFC Series and
   the RFC Editor is being adjusted to work more directly with the RFC
   Editor and provide oversight to ensure the RFC Series mission
   principles and communities' input are addressed appropriately.

   This section provides an overview of the role of the IAB with respect
   to the RFC Editor as it has been presented in IAB Charter RFCs dating
   back to 1992.  The point of this section is that the IAB's role has
   historically been substantive -- whether it is supposed to be
   directly responsible for the RFC Series' editorial management (circa
   1992, Appendix A.1), or appointment of the RFC Editor organization
   and approval of general policy (circa 2000, Appendix A.3).

A.1.  1992

   [RFC1358] says:

   [The IAB's] responsibilities shall include:
   [...]
       (2)  The editorial management and publication of the Request for
            Comments (RFC) document series, which constitutes the
            archival publication series for Internet Standards and
            related contributions by the Internet research and
            engineering community.
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A.2.  1994

   [RFC1601] says:

  [The IAB's] responsibilities under this charter include:

   (d) RFC Series and IANA

      The IAB is responsible for editorial management and publication of
      the Request for Comments (RFC) document series, and for
      administration of the various Internet assigned numbers.

  which it elaborates as

   2.4 RFC Series and Assigned Numbers

      The RFC Series constitutes the archival publication channel for
      Internet Standards and for other contributions by the Internet
      research and engineering community.  The IAB shall select an RFC
      Editor, who shall be responsible for the editorial management and
      publication of the RFC Series.

A.3.  2000

   [IABCHARTER], which is the most recent IAB Charter document, says:

   (d) RFC Series and IANA

   The RFC Editor executes editorial management and publication of the
   IETF "Request for Comment" (RFC) document series, which is the
   permanent document repository of the IETF.  The RFC Series
   constitutes the archival publication channel for Internet Standards
   and for other contributions by the Internet research and engineering
   community.  RFCs are available free of charge to anyone via the
   Internet.  The IAB must approve the appointment of an organization to
   act as RFC Editor and the general policy followed by the RFC Editor.
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